A token is a physical device that can be used for authenticating a user. For example, the SecurID token is manufactured by RSA Security, Inc. of Bedford, Mass. The SecurID token displays a unique code generated by the RSA SecurID or AES industry-standard hash algorithm in combination with the unique symmetric key contained in the token. Augmented by an internal clock, the algorithm generates a new authentication code every 60 seconds for the programmed life of the token. The RSA SecurID PINPad Card (SD520) permits the user to enter his Personal Identification Number (“PIN”) via a 10-digit numeric keypad that is contained on the card. The code displayed is a hash-encrypted combination of the PIN and the current authenticator code. To be authenticated, the user provides the authentication code displayed on the SecurID token to an RSA ACE/Server. The ACE/Server already stores the PIN and symmetric key of each PINPad card and includes software that can generate the same authenticator codes as are generated by the tokens. If the authentication code from the token matches that generated by the ACE/Server for the given 60 second time period, then the user is authenticated by the ACE/Server.
Another type of token uses a challenge and a response to authenticate the user. The user receives a challenge from a server. The challenge can be a series of numbers resembling a telephone number. The user activates the token with a PIN and enters the challenge using a keypad on the token. The token applies a predetermined algorithm known by the server to the challenge, and generates and displays to the user a response. The user provides the response to the server, which internally generates its own version of the response, based upon it's preexisting knowledge of a key in the token, the PIN and the authentication code generation algorithm. If the user response provided to the server matches the anticipated response generated internally by the server, then the user is authenticated.
Hardware tokens such as the SecurID and the challenge-response token (hereinafter, “stand-alone hardware tokens”) provide authentication, but cannot provide information to another party (such as the authenticating server) beyond that which can be entered by a user. For example, the SecurID token cannot provide a public key to the server. Likewise, the processing capability of stand-alone hardware tokens are oriented entirely towards generating a time-based or challenge-response authenticator. They cannot, for example, verify the signature of a message by using another's public key. The cannot securely store and provide sensitive information (e.g., a user's credit card number, medical information, etc.) because they cannot communicate electronically with another entity.
RSA also manufactures “software tokens.” RSA SecurID Software Tokens use the same algorithms as RSA SecurID hardware tokens. Instead of residing within the plastic case of an RSA SecurID hardware token, the symmetric key is stored in a tamper-resistant fashion on a user's desktop, laptop, PDA, Smart Phone or Smart Card.
For example, the RSA SecurID software token for the Ericsson R380s cellular telephone is designed to authenticate valid network users. The RSA SecurID software for the Ericsson R380s generates a unique, unpredictable access code for secure network access. As for other RSA tokens, this code is combined with the user's secret PIN to create a dynamic code that is verified by the RSA ACE/Server software protecting the network. This constitutes a two-factor authentication system, where access to the network requires that the user prove he knows a given secret (such as a PIN) and also that he has a given item, such as a hardware or software token. Software tokens are generally only as secure as the platform on which they are installed. For example, if any tamper-resistant measures that may be applied to the memory of the Ericsson R380s can be breached, then the software token may subject to unauthorized modification. This could subvert the security of the software token, e.g., lead to the unauthorized disclosure of a secret key.
Yet another type of token is a smartcard. A smartcard can include a tamper-resistant processor and memory that can store a credential of the user, along with means to electronically communicate with another entity. An example of such a credential is a private key and a certificate associated with the user of the smartcard. The certificate can include the public key that corresponds to the user's private key; a user identifier; an expiration date; and other information. A smartcard can also store sensitive information (e.g., user medical information) with safeguards against unauthorized disclosure. A smartcard can communicate electronically by having electrical contacts suitable for connecting with a receiving device (a smartcard reader). A smartcard can also communicate with another device via wireless technology, e.g., over radio frequency waves. A smartcard can be used to authenticate a user by inserting it into a reader, or activating a wireless smartcard to communicate with a device. The receiving entity can require the user to input a shared secret, such as a PIN, to provide assurance that the user is utilizing his own smartcard, and not a stolen one. The smartcard (and by extension, its owner) can then be electronically authenticated by the receiving device.
A smartcard has more processing and storage capability than a stand-alone hardware token, but does not include a keypad. A user can provide input in conjunction with smartcard by connecting the smartcard to a reader that has a keypad. But there is no standalone keypad on the smartcard itself. The smartcard and reader combination lacks the portability of a smartcard alone or a stand-alone token.